Relational databases are well known in the art. A relational database is a database that conforms to a relational model, and refers to a database's data and schema (the database's structure of how the data is arranged). A relational database is usually managed through the use of a Relational Database Management System (RDBMS). Many different RDBMS products are currently available, including ones produced by the assignee of the present application.
A user, by either directly querying the database or through an application program that queries the database, may ask questions of the database regarding the currently stored data and schema and receive responses from the database based on the data and model that is currently stored. As a simple example, consider a relational database that stores the employment information for employees of an enterprise. The database may contain information such as an employee id, a name, an address, a salary level, and any other information the enterprise deems relevant. A user can ask a question of the database, such as requesting a list of all employee ids of employees whose salary is less than a certain amount. The RDBMS will be able to process this request and return the answer to the user.
Present day RDBMS systems are well suited to answering questions about the data that is currently stored in the database, such as the question presented above. However, RDBMS systems are not well suited to answering such questions when presented with additional criteria, such as a time relationship. In many situations, a user will not need to ask questions of the database that reflect the current status, but may need to query the database regarding a status from the past, or potentially the future. Continuing with the example, a user may need to request a list of all employee ids whose salary was below a certain amount on a certain date in the past. This question cannot be answered by a query of the database as it exists today, because any number of events may have happened between the date of interest and the present. Employees may have received raises or reductions in salary, or employees may have been hired or fired, thus making the values stored in the database as of today unrelated to the values as they existed in the past.
Additionally, present day RDBMS systems are not well suited to answering questions across time when the underlying schema has changed. Continuing with the employment information database, consider the case where a new field of information is added to the schema of the database, such as a new field indicating an employees marital status. If the database is asked a question about an employees marital status six months ago, it would be unable to provide an accurate answer, as that particular field did not exist at the time of interest. Simply providing the status as it exists today would be inaccurate, as this may not reflect the true marital status of the employee as there is the potential the employee's status changed in the last six months. The most accurate answer may be that six months ago, the employee marital status was not known because that field did not exist in the database. However, because RDBMS systems today do not keep track of changes made to the underlying data model, it would be unknown when the marital status field was added.
There have been attempts to solve the temporal problem of RDBMS systems, however these solutions are all inadequate for a variety of reasons. For example, many database systems will keep an audit log of changes that have been made to data values across time. However, this does not provide for effective querying across time because every query would involve recreating the database through an enormous listing of audit logs. Additionally, many database systems will attempt to overcome the problem of changes in a database schema by taking periodic snapshots of the database as it exists at the time of the snapshot. This solution is ineffective because of ongoing changes in the values of the data currently stored, and a snapshot of the database may not reflect current realities. Additionally, applications that access the database are generally updated when a new database schema is deployed. Using the snapshot model requires not only saving multiple copies of the database for every point in time, but also multiple copies of all applications that access the database for every point in time.
Although there has been some research done in the field of temporal databases, this research has been focused on the problems associated with maintaining a temporal history of data values only. Although this may be useful in some situations, a fully temporal database must support not only temporal histories of data, but of the underlying model as well.
Embodiments of the present disclosure attempt to solve problems such as those mentioned above, as well as others that would be readily known to one of skill in the art.